プロジェクト 2501

概要

忙しかった山が一段落 + 趣味も安定稼動したので、

そうだ、人形使いつくろう！　みたいな感じ。

複数クライアントでのデバッグと操作介入のツールを作ることにした。

これ。

2501

モチベーション is 何

・別のゲームに接続しているClient群の監視、制御を行う

・デバッグ、ゲームサーバからは独立した、Client依存のbotづくり

目的と手段

・内包しているnginxでClient群からのWebSocketを受け、だいたいリアルタイムでClient群についてログる

・接続しているClientへのコマンド代入を行う

(nginxでlua動かして、virtualClientからのコマンドをWebSocket経由でクライアントに送る)

これができると、また別の意味でのOrchestrationが出来るようになると思う。Orchestration言いたいだけ。

あと個人的に遊びでlua使いたい。

リアルタイムログもClientOrchestrationも

本来ゲームサービス側が保持すべき性能なんだけど、なかなか実際の仕事でゲームサーバ側がリアルタイムログ集計、コマンド仮送りをするのが難しい。

リアルタイムログ集計

ほとんどのゲームは、動作するのに必要以上のリアルタイムログを必要としない。つまりゲーム本来の目的とは合わない。

ただ単に、サービスが求めるリアルタイム性みたいなのと関係ないデータをゲームサーバに送りつづけることそれ自体が不効率だ。

なのでどっか別のところでリアルタイムに見れるように出来れば面倒さが無い。

コマンド代入

先月？のJenkins Confで少し話していたのだけど、ゲームの自動プレイを行う領域をどこに持つべきか、って話で、

サーバからOrchestrationできればいいのにねーって話していたが

・Client-Server間で進捗が別途であること

・Clientの状態が存在することを考えるとサーバ側が後手に回らざるをえないこと

とかを加味すると、現実的ではない感じがした。

ので、

・Clientに直結

・Clientが受け入れ可能な状態とシンクロしたコンテキストを持つ

という前提で動くものを作ってみたくなった。

コンテキストまでどうシンクロさせるのか、とかは考え中。

Why WebSocket

ブラウザにも繋ぐ事が出来る。

現在

WebSocketServerをUnityで試作した。

Application寄りすぎて使いづらいので、nginxとか内包する感じで再設計する。